NHG with Unequal Cost Members#2302
Conversation
| * @flags CREATE_AND_SET | ||
| * @default false | ||
| */ | ||
| SAI_NEXT_HOP_GROUP_ATTR_MEMBERS_WITH_UNEQUAL_WEIGHTS, |
There was a problem hiding this comment.
@JaiOCP, what is the additional benefit of querying this capability?
If NOS is configured to program unequal paths, NOS can directly add those members to the NHG with the required weights, right? I believe we don't need any additional hardware capability/support to handle unequal-cost paths in this case.
Please let me know if I am missing any specific use case where this capability is required.
There was a problem hiding this comment.
For the legacy implementation, yes.
For newer implementation where there is a dedicated resource for weight NHG vs unweighted NHG, we need to differentiate the NHG during NHG create.
Now you can make an argument that why not a new NHG type instead of a bool. Problem with that approach is that NHG may be of any type with members as wieghted or unweighted. Hence the introduction of a new bool attribute.
|
There is a case where NHG need to allocated differently for ECMP and UCMP for highly optimized fabrics.This PR addresses that case.On Jun 22, 2026, at 8:26 PM, sathk-marvell ***@***.***> wrote:
@sathk-marvell commented on this pull request.
In inc/sainexthopgroup.h:
@@ -359,6 +359,19 @@ typedef enum _sai_next_hop_group_attr_t
*/
SAI_NEXT_HOP_GROUP_ATTR_ADMIN_ROLE,
+ /**
+ * @brief This attribute indicates the nexthop group members weights
+ *
+ * NOS must query this attribute for the support.
+ * False: All members are with equal cost
+ * True: Members are configured with unequal cost
+ *
+ * @type bool
+ * @flags CREATE_AND_SET
+ * @default false
+ */
+ SAI_NEXT_HOP_GROUP_ATTR_MEMBERS_WITH_UNEQUAL_WEIGHTS,
@JaiOCP, what is the additional benefit of querying this capability?
If NOS is configured to program unequal paths, NOS can directly add those members to the NHG with the required weights, right? I believe we don't need any additional hardware capability/support to handle unequal-cost paths in this case.
Please let me know if I am missing any specific use case where this capability is required.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Signed-off-by: JaiOCP <jai.kumar@broadcom.com> NHG with UECMP Signed-off-by: JaiOCP <jai.kumar@broadcom.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: JaiOCP <jai.kumar@broadcom.com>
|
@eddyk-nvidia @rck-innovium @tjchadaga Changes made as per the review. |
| * NOS must query this attribute for the support. | ||
| * False: All members are with equal cost | ||
| * True: Members are configured with unequal cost | ||
| * @brief This attribute indicates if all the members are with weights or are unweighted |
There was a problem hiding this comment.
-
Please add some more text to bring out that this attribute is an hint. For e.g., a NOS can set the type as SAI_NEXT_HOP_GROUP_MEMBERS_WEIGHT_WEIGHTED and still not give any weights to the members. On the other hand, if the NOS sets the type as SAI_NEXT_HOP_GROUP_MEMBERS_WEIGHT_UNWEIGHTED, the NOS MUST NOT give any weights to the members.
"This attribute is for the NOS to provide a hint that members of this group will be created with weights. When this is set as SAI_NEXT_HOP_GROUP_MEMBERS_WEIGHT_UNWEIGHTED, it allows the SAI implementation to optimize hardware resources for ECMP."
-
We need to describe the relationship with SAI_NEXT_HOP_GROUP_ATTR_TYPE.
Example:
@validonly SAI_NEXT_HOP_GROUP_ATTR_TYPE == SAI_NEXT_HOP_GROUP_TYPE_DYNAMIC_UNORDERED_ECMP or SAI_NEXT_HOP_GROUP_ATTR_TYPE == SAI_NEXT_HOP_GROUP_TYPE_DYNAMIC_ORDERED_ECMP
There was a problem hiding this comment.
Hi Ravi,
-
Your first sentence is what we have today. Instead of adding detail for each type in comment (and go out of space) I have added comments in the sai_next_hop_group_members_weight_t stating what each enum means. We can extend that if you think it needs more details.
-
I though about it and this attribute will be valid for almost all the NHG types. For example PROTECTION NHG can be weighted or unweighted as well. Today we do not distinguish for any NHG type that if it can be weighted or unweighted. So I felt that adding a valid would break the backward compatibility.
5 participants
This PR brings in support for high performant fabric where NHG is created with prior information about the members with weights.
NOS can use sai_query_attribute_capability() to find out if the platform supports such behavior or not. Legacy implementation will always return the status as not supported attribute.